1. Technical Field
This disclosure relates generally to business process automation functionality and, in particular, to techniques for extending such automation to include identity management information.
2. Background of the Related Art
Increasingly, executives are placing service-oriented architecture (SOA) and Web services on their corporate agendas. An SOA is an application framework that supports componentized business processes, freeing functions and data from their applications so that they can be accessed by and extended to whomever a company chooses. A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable. Useful business processes make and save money for an enterprise. Web services is a collection of standard technologies that, when applied to an SOA, removes the need for custom coding, resulting in reduced development costs and increased business flexibility and responsiveness. These technologies help businesses increase revenue and efficiency by enabling them to become more flexible and responsive.
Today Web services can communicate with each other, advertise themselves, and be discovered and invoked using industry-wide specifications. To link these services together in a business process, the Business Process Execution Language for Web Services (BPEL4WS) specification may be used. BPEL4WS facilitates creation of complex processes by creating and wiring together different activities that can, for example, perform Web services invocations, manipulate data, throw faults, or terminate a process. These activities may be nested within structured activities that define how they may be run, such as in sequence, or in parallel, or depending on certain conditions. In addition to being an implementation language, BPEL4WS can be used to describe the interfaces of business processes using a notion of abstract processes.
As an enterprise moves to a SOA environment, however, often it is the case that assumptions that have been made about the environment, request flow, and user access to resources, no longer hold. For example, internal users (such as enterprise employees) are often used to (but not necessarily pleased with) the multiple authentications required to access all of the resources necessary to complete a given task. As the enterprise opens up to its partners its internal applications or business processes, it is undesirable for the “partner-users” to have to go through this repeated authentication. To simplify this process, single sign-on (SSO) techniques can be used to map a partner user to a locally-known identifier value that represents the user's identity at the SSO point. As the partner-user invokes more complex business processes, however, there is no easy way to know how, where or when to map or transform the user's identifier into a locally-valid identifier that is applicable to that point in the overall business process. In particular, there is no process or policy-based based means of transforming a user's identity (or, more specifically, credentials) as part of enabling transaction fulfillment within a SOA environment. This information is required, however, to ensure that a request has the appropriate processing (including access control decisions based on the request and the requestor's identity and attributes) applied.
Identity management is a main aspect of enterprise security, and it typically comprises identity authentication, resource access authorization, and event logging for auditing compliance. Identity management systems and techniques are well-developed in the art.